Deployment Architecture

This topic describes the BAM deployment architecture.

The BAM deployment environment is used to deploy and publish the definitions of BAM artifacts created using editors in design- time. The definitions of BAM artifacts are packaged as applications, deployed in target environment and published or configured per organization. The Deployment-time flow is depicted as follows:

BAM artifacts are selected from the artifact viewer and published or configured per organization. Following runtime artifacts are created when publish or configuration is completed.

1. Process Monitoring Object
   A Process Monitoring Object is exposed to the users as a set of attributes, with different data types. While defining queries on Business Measure Editor, users can work as if each attribute has a dedicated column in database table reserved per Process Monitoring Object, but internally all the Process Monitoring Objects are stored in a generic database schema since the dynamic table creation is not permitted in many customer deployment environments. When a Process Monitoring Object is published then its attributes, data type and column-map information are stored at Objects Meta data repository in BAM database.
   
   
2. Business Measure
   Each Business Measure is published as a separate Web service and attached to the BAM Monitoring Service, available in that particular organization. This enables better enforcement of data security as each BAM Monitoring Service processes data or events pertaining to that organization only, though they can access common BAM database.
   
   Each Business Measure has SQL query as internal implementation. While publishing the Business Measures, queries defined on the Process Monitoring Objects and EDOs are compiled to the SQL queries, executable on BAM Objects database and EDO tables.
   
   
3. KPI Monitor
   Monitoring of KPIs is configured through the KPI editor, where the user specifies the time interval (for which KPI data that the user wants to monitor) as parameters, ranges and actions (to trigger when a KPI value falls in those ranges) ; and the scheduled intervals (when to monitor the KPIs). Each KPI Monitor is created as separate Web service from the data security perspective and easier integration with external tools.
   
   When a KPI Monitor is published then a Web service is created in the Process Platform Web service repository and attached to BAM Monitoring Service, in that particular organization. Monitoring schedule is deployed with the Cordys scheduler. Rules are created with the defined ranges and actions. For firing of rules on the insertion of KPI Monitor objects, correspondingly with range definitions, a template is created per KPI Monitor. For actions of 'type email', Web service is created per the email template.
   
   
4. Business Event Response
   From data architecture perspective, an implicit Process Monitoring Object is created per Business Event Response and based on event condition definition the corresponding event meta data is stored in BAM database. For working of event rules, a template is created per Business Event Response, along with associated rules and actions. For actions of 'type email', Web service is created per email template.
   
   
5. Dashboard
   Dashboard definition is now part of Process Platform XForms designer. Once the dashboard is created by dragging and dropping the Business Measures and KPI composite controls, you have to assign the XForm should to any required role and are view it. Organizations would like to assign the dashboards to any organization role and for that purpose, access of BAM dashboards are not dependent on any BAM application role. Only 'everyOneInBAM' role is required for execution of the Business Measures, which are part of dashboard views.